1. Field of the Invention
The present invention relates to a system and method for managing XDM (XML Document Management) service information used to provide Open Mobile Alliance (OMA) service.
2. Description of the Related Art
As mobile telecommunication technologies have developed and communication networks have become more common, users have increasingly demanded various additional mobile telecommunication services. Accordingly, Open Mobile Alliance (OMA) services such as Push-to-Talk over Cellular (PoC), Instant Messaging (IM) and the like have been suggested to
Service information is required to provide various OMA services. The service information may be classified into information shared among several OMA services and information used only by specific OMA service. The service information shared among several OMA services is stored in an OMA shared XML document management system (XDMS), hereinafter referred to as a “shared XDMS.”
FIG. 1 is a block diagram illustrating group management and presence architecture for managing OMA service information. Referring to FIG. 1, the group management and presence architecture may include an XDM client 100, an aggregation proxy 110, a shared XDMS 120, a resource list server (RLS) XDMS 130, a resource list server (RLS) 132, a PoC XDMS 140, a PoC server 142, a presence XDMS 150, a presence server 152, and an SIP/IP (Session Initiation Protocol/Internet Protocol) core 160.
The XDM client 100 is for using group information. The XDM client 100 is a service requester embedded in a user terminal and connected to XDM servers either through Aggregation Proxy 110 using HTTP, or through SIP/IP core 160 which is a core network supporting SIP and IP multimedia. The XDM client 100 can obtain and process group list information for a group call service. The XDM client is defined in an OMA standard.
The XDM servers (XDMSs) 120, 130, 140, and 150 are used for group list service. These servers are also defined in the OMA standard. The XDM servers (XDMSs) 120, 130, 140, and 150 may be classified into the RLS XDMS 130, the PoC XDMS 140, and the presence XDMS 150 for providing specific OMA service, and the shared XDMS 120, which may be shared with other service enablers.
A user can input information about groups and group members to the XDMS 120, 130, 140 and 150 using the XDM client 100. Herein, the term user will be regarded as having the same meaning as XDM client, unless mentioned otherwise.
When a group list related request is received from the user, the aggregation proxy server 110 routes the request to the XDMSs 120, 130, 140, and 150 according to a suitable rule.
The RLS 132 utilizes a presence information group maintained in RLS XDMS 130, to subscribe the presence information of the group members. The PoC server 142 utilizes a PoC group information maintained in PoC XDMS 140, to manage a PoC session. The presence server 152 manages current state or presence information of users.
The SIP/IP CORE 160 is connected to the XDMSs 120, 130, 140, and 150, the PoC server 142, and the RLS 132 to provide OMA service.
As described above, the RLS XMDS 130 and the PoC XDMS 140 store RLS service information and PoC service information, respectively. The shared XDMS 120 stores shared service information which is used for several OMA services. The PoC service information and the RLS service information are generally created to refer to the shared service information, which is stored in the shared XDMS 120. The shared XDMS 120 may also store service information used only for the XDMS. This service information is also created to refer to the shared service information.
A representative example of the service information includes a uniform resource identifier (URI) list. The URI list stored in the shared XDMS 120 and used for a plurality of OMA services is called a shared URI list.
The shared URI lists typically have a resource-list format corresponding to an XCAP_LIST [XCAP (XML Configuration Access Protocol)-list].
Tables 1 and 2 below, illustrate XML schema for a resource-list, as specified in “The Extensible Markup Language (XML) Formats for Representing Resource List”, J. Rosenberg, Feb. 7, 2005, herein after referred to as [XCAP_List].
TABLE 1XML schema for resource-list; part 1 [XCAP_List]<?xml version=“1.0” encoding=“UTF-8”?> <xs:schema targetNamespace=“urn:ietf:params:xml:ns:resource-lists”  xmlns=“urn:ietf:params:xml:ns:resource-lists”  xmlns:xs=“http://www.w3.org/2001/XMLSchema”  elementFormDefault=“qualified” attributeFormDefault=“unqualified”>  <xs:import namespace=“http://www.w3.org/XML/1998/namespace”  schemaLocation=“http://www.w3.org/2001/xml.xsd”/>  <xs:complexType name=“listType”>  <xs:sequence>   <xs:element name=“display-name” type=“display-nameType”minOccurs=“0”/>   <xs:sequence minOccurs=“0” maxOccurs=“unbounded”>   <xs:choice>    <xs:element name=“list”>    <xs:complexType>     <xs:complexContent>     <xs:extension base=“listType”/>     </xs:complexContent>    </xs:complexType>    </xs:element>    <xs:element name=“external” type=“externalType”/>    <xs:element name=“entry” type=“entryType”/>    <xs:element name=“entry-ref” type=“entry-refType”/>    <xs:any namespace=“##other” processContents=“lax”    minOccurs=“0”    maxOccurs=“unbounded”/>   </xs:choice>   </xs:sequence>   <xs:any namespace=“##other” minOccurs=“0”    maxOccurs=“unbounded”/>  </xs:sequence>  <xs:attribute name=“name” type=“xs:string” use=“optional”/>  <xs:anyAttribute namespace=“##other”/>  </xs:complexType> <xs:complexType name=“entryType”>  <xs:sequence>   <xs:element name=“display-name” minOccurs=“0”>   <xs:complexType>    <xs:simpleContent>    <xs:extension base=“display-nameType”/>    </xs:simpleContent>   </xs:complexType>   </xs:element>  <xs:any namespace=“##other” processContents=“lax”  minOccurs=“0”   maxOccurs=“unbounded”/>  </xs:sequence>  <xs:attribute name=“uri” type=“xs:anyURI” use=“required”/>  <xs:anyAttribute namespace=“##other”/> </xs:complexType>
TABLE 2XML schema for resource-list; part 2 [XCAP_List] <xs:complexType name=“entry-refType”>  <xs:sequence>   <xs:element name=“display-name” type=“display-nameType”minOccurs=“0”/>   <xs:any namespace=“##other” minOccurs=“0”   maxOccurs=“unbounded”/>  </xs:sequence>  <xs:attribute name=“ref” type=“xs:anyURI” use=“required”/>  <xs:anyAttribute namespace=“##other”/>  </xs:complexType>  <xs:complexType name=“externalType”>  <xs:sequence>   <xs:element name=“display-name” type=“display-nameType”minOccurs=“0”/>   <xs:any namespace=“##other” minOccurs=“0”   maxOccurs=“unbounded”/>  </xs:sequence>  <xs:attribute name=“anchor” type=“xs:anyURI”/>  <xs:anyAttribute namespace=“##other”/>  </xs:complexType>  <xs:element name=“resource-lists”>  <xs:complexType>   <xs:sequence maxOccurs=“unbounded”>   <xs:element name=“list” type=“listType”/>   </xs:sequence>  </xs:complexType>  </xs:element>  <xs:complexType name=“display-nameType”>  <xs:simpleContent>   <xs:extension base=“xs:string”>   <xs:attribute ref=“xml:lang”/>   </xs:extension>  </xs:simpleContent>  </xs:complexType> </xs:schema>
A shared URI list created according to the schema of Tables 1 and 2 is stored in the form of a resource-list document in a user directory for a user who possesses a shared URI list in the shared XDMS 120.
Table 3 shows an example of a resource-list document having the name friends.xml.
TABLE 3Example resource-list document in Shared XDMS, named friends.xml<?xml version=“1.0” encoding=“UTF-8”?> <resource-lists xmlns=“urn:ietf:params:xml:ns:resource-lists”     xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>  <list name=“my_friends”>   <display-name>My Friends</display-name>   <entry uri=“sip:brian@example.com”>    <display-name>Brian Oh</display-name>   </entry>   <entry uri=“sip:alex@example.com”>    <display-name>Alex Cho</display-name>   </entry>  </list>  <list name=“other_friends”>   <display-name>Other Friends</display-name>   <entry uri=“sip:joe@example.com”>    <display-name>Joe Smith</display-name>   </enrty>   <entry uri=“sip:nancy@example.com”>    <display-name>Nancy Gross</display-name>   </entry>  </list> </resource-lists>
The location of the resource-list document stored in the shared XDMS 120 is represented by an XCAP URI of [XCAP Root URL]/[AUID]/users/[XUI]/[XML document name] format, details of which are described in “XML Document Management (XDM) Specification”, Version 1.0, Open Mobile Alliance™, OMA-TS-XDM_CORE-V1—0, herein after referred to as [XDM_Core]. This format is called a document selector because it specifies a location of an XML document. The XCAP Root URL indicates a top-level entity of all XDMSs, the AUID (application ID) indicates corresponding service, and the XUI (XCAP user identity) indicates an owner of the document. The AUID for a resource-list defined in [Shared_XDM] is “resource-lists.” Accordingly, a document selector of a resource-list document becomes [XCAP Root URL]/resource-lists/users/[XUI]/[XML document name].
For example, assuming that [XCAP Root URL] to which the shared XDMS belongs is http://xcap.example.com/services, and an owner of a resource-list document friends.xml in Table 3 is Jay, whose XUI is sip:jay@example.com, a document selector of the friends.xml document is http://xcap.example.com/services/resource-lists/users/sip:jay@example.com/friends.xml. This document selector is used as an XCAP URI specifying the location of the document.
A location of each element stored in the resource-list document is represented by a combination of a document selector and a node selector. A location representation format is [document selector]/˜˜/[node selector]. The node selector represents a location of an element corresponding to a described condition using a certain method.
Table 4 illustrates code used to define the node selector as specified in “The Extensible Markup Language (XML) Configuration Access protocol (XCAP)”, J. Rosenberg, Jun. 11, 2005, hereafter referred to as [XCAP].
TABLE 4Advanced BNF definition for node selector [XCAP]node-selector= element-selector [“/” attribute-selector] element-selector= step *( “/” step) step= by-name / by-pos / by-attr / by-pos-attr by-name= NameorAny by-pos= NameorAny “[“ position ”]” position = 1*DIGIT by-attr= NameorAny “[“ “@” att-name “=” <‘’> att-value <‘’> ”]” by-pos-attr= NameorAny “[“ position ”]” “[“ “@” att-name “=” <‘’> att-value <‘’> ”]” NameorAny = QName / “*” ; QName from XML Namespaces att-name = QName att-value = AttValue  ; from XML specification attribute-selector = “@” att-name
For example, when in the friends.xml document in Table 3, a location of a <list> element having a name of my_friends among <list> elements which are child elements of a <resource-lists> root element is to be specified, http:xcap.example.com/services/resource-lists/users/sip:jay@example.com/friends.xml/˜˜/resource-lists/list[@name=“my_friends”] and this becomes an XCAP URI of the <list> element the value of whose ‘name’ attribute is “my13friends”.
An owner of the shared URI list stored in the shared XDMS 120 is a user who has created the list. Accordingly, modification, deletion, and utilization of the shared URI list are unique rights of the user possessing the list. For example, a user identified by sip:jay@example.com has created the friends.xml document in Table 3 and becomes the owner of friends.xml, a resource-list document. As such, it is only the user, sip:jay@example.com, who can modify the contents of the document, utilize the document, and delete the document.
Meanwhile, as described above, the shared URI list stored in the shared XDMS 120 may be referred to by several OMA services. A procedure of creating the shared URI list and utilizing it through a reference in OMA services will be described with reference to the accompanying drawings.
FIG. 2 illustrates an example of a procedure for creating and utilizing a shared URI list. As shown in FIG. 2, the user, i.e., the XDM client 100, creates its shared URI lists in the form of a resource-list document as shown in Table 3, and stores the lists in a prescribed location or the user directory of the user within the shared XDMS 120 using an HTTP PUT message of an XCAP protocol. The Request URI of the HTTP PUT message is the document selector of XCAP URI, which is; http://xcap.example.com/services/resource-lists/users/sip:jay@example.com/friends.xml. The HTTP PUT message is first sent to the aggregation proxy 110 (201). The aggregation proxy 110 then routes the message to the shared XDMS 120 using the application ID of the “resource-lists”, which is specified within the above XCAP URI (203). Then, the HTTP PUT message is used for requesting the shared XDMS 120 to create the friends.xml document under the user directory named with the XUI of sip:jay@example.com. Further, the user creates friends2.xml document referring to friends.xml and provides it to the shared XDMS 120 (209 and 211), creates an rls.xml document referring to the friends.xml document and provides the rls.xml document_to the RLS XDMS 130 (217 and 219), and creates a poc_group.xml document referring to the friends.xml and provides the a poc_group.xml document_to the PoC XDMS 140 (225 and 227). The creation of the friends2.xml, rls.xml, and poc_group.xml documents is performed through the aggregation proxy 110. HTTP201 Created response messages 205, 207, 213, 215, 221, 223, 229, and 231 are sent to the user to indicate the successful creation of each document.
The shared URI lists created in the shared XDMS 120 can be referenced by <external> element, <resource-list> element, or <entry-ref> element. <external> element is used to refer to a <list> element in shared URI lists which indicates a group of shared members. Similarly to <external> element, <resource-list> element is used to refer to a <list> element indicating the shared group, but can only be utilized in an RLS Service[RLS_XDM]. <entry-ref> element is used to refer to the <entry> element in shared URI lists which indicate a shared member. These referencing elements enable the shared URI lists to be referenced or utilized in OMA services including the shared XDMS 120 itself. Additionally, these referencing elements act as a type of pointer to the shared URI list in the shared XDMS 130. Resolution for a <list> element and an <entry> element in the shared URI list referred to through the pointers is made by the respective subjects (e.g., PoC server or RLS server) that actually use the service.
Table 5 to 7 shows examples of the above described reference mechanism.
TABLE 5Example resource-list document in Shared XDMS, named friends2.xml<?xml version=“1.0” encoding=“UTF-8”?> <resource-lists xmlns=“urn:ietf:params:xml:ns:resource-lists”     xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>  <list name=“list1”>   <display-name>Applied List 1</display-name>   <entry uri=“sip:member1@example.com”/>   <list name=”nested_list1”>    <entry uri=”nested_member1@example.com”/>    <entry uri=”nested_member2@example.com”/>   </list>   <entry-ref ref=“resource-lists/users/sip:jay@example.com/friends.xml/--/resource-lists/list[@name=”my_friends”]/entry[@uri=“sip:brian@example.com”]”>    <display-name>Pointer to entry element at my_friends.xml</display-name>   </entry-ref>   <external anchor=”http://xcap.example.com/services/resource-lists/users/sip:jay@example.com/friends.xml/--/resource-lists/list[@name=”other_friends”]”>    <display-name>Pointer to list element at my_friends.xml</display-name>   </external>  </list> </resource-lists>
TABLE 6Example rls document in RLS XDMS, named rls.xml<?xml version=“1.0” encoding=“UTF-8”?> <rls-services xmlns=“urn:ietf:params:xml:ns:rls-services”      xmlns:rl=“urn:ietf:params:xml:ns:resource-lists”     xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>  <service uri=“sip:rls-service1@example.com”>  <resource-list>http://xcap.example.com/services/resource-lists/users/sip:jay@example.com/friends.xml/--/resource-lists/list[@name=”other_friends”]</resource-list>  <packages>  <package>presence</package>  </packages>  </service>  <service uri=“sip:marketing@example.com”>   <list name=“marketing”>   <rl:entry uri=“sip:joe@example.com”/>   <rl:entry uri=“sip:sudhir@example.com”/>   <rl:entry-ref ref=“resource-lists/users/sip:jay@example.com/friends.xml/--/resource-lists/list[@name=”my_friends”]/entry[@uri=“sip:brian@example.com”]”>   </entry-ref>   <rl:external anchor=”http://xcap.example.com/services/resource-lists/users/sip:jay@example.com/friends.xml/--/resource-lists/list[@name=”other_friends”]”>   </external>   </list>   <packages>   <package>presence</package>   </packages>  </service> </rls-services>
TABLE 7Example PoC group document in PoC XDMS, named poc_group.xml<?xml version=“1.0” encoding=“UTF-8”?><group xmlns=“urn:oma:params:xml:ns:listservice”    xmlns:rl=“urn:ietf:params:xml:ns:resource-lists”    xmlns:cr=“urn:oma:params:xml:ns:common-policy”> <list-scrvice uri=“sip:myconference@example.com”>  <list>   <entry uri=“tel:443012345618”/>   <entry uri=“sip:hermione.blossom@example.com”/>   <external anchor=“http://xcap.example.com/services/resource-lists/users/sip:jay@example.com/friends.xml/--/recource-lists/list[@name=”other_friendes”]”>   </external>  </list>  <display-name xml:lang=“en-us”>Friends</display-name>  <max-participant-count>10</max-participant-count>  <cr:ruleset>   <cr:rule id=“a7c”>    <cr:conditions>     <is-list-member/>    </cr:conditions>    <cr:actions>     <join-handling>allow</join-handling>     <allow-anonymity>true</allow-anonymity>    </cr:actions>   </cr:rule>  </cr:ruleset> </list-service></group>
Table 5 shows friends2.xml document in the shared XDMS 120, in which <entry-ref> element and <external> element are used to refer to <entry> element and <list> element in shared URI lists, respectively. More specifically, the shared URI list refers to the <list> element having a list name of ‘other_friends’ and to the <entry> element having the URI of ‘sip:brian@example.com’ in the shared URI lists named as the friends.xml, by using an <external> element and an <entry-ref> element, respectively.
Table 6 shows rls.xml document in the RLS XDMS 130, in which <entry-ref> element and <resource-list> element are used to refer to <entry> element and <list> element in shared URI lists, respectively. More specifically, the <service> element with the service URI of ‘sip:rls-service1@example.com’ refers, by using <resource-list> element, to the <list> element having the list name of ‘other_friends’ in the shared URI list stored in the friends.xml resource-list document in the shared XDMS 120. Similarly, the <service> element with the service URI of ‘sip:marketing@example.com’ refers to the <list> element having the list name of ‘other_friends’ in the shared URI list stored in the friends.xml resource-list document by using <external> element, and refers to the <entry> element having the URI of ‘sip:brian@example.com’ in the shared URI list stored in the friends.xml resource-list document by using the <entry-ref> element.
Table 7 shows poc_group.xml document in the PoC XDMS 140, in which <entry-ref> element and <resource-list> element are used to refer to <entry> element and <list> element in shared URI lists, respectively. More specifically, the PoC group member listing refers, by using the <external> element, to the <list> element having a list name ‘other_friends’ in the shared URI list stored in the friends.xml resource-list document in the shared XDMS 120.
The following describes reference handle with respect to the above examples.
The XML schema definition for the <external> element and the <entry-ref> element is shown in Table 1. The <external> element refers to a <list> element by specifying the absolute XCAP URI of the <list> element to be referred, which is entire path to the element. For example, in Table 5, the location of the <list> element in the shared URI list referred to by the <external> element is specified by an absolute XCAP URI of:
http://xcap.example.com/services/resource-lists/users/sip:jay@example.com/friends.xml/˜˜/resource-lists/list[≠ name=“other_friends”].
In the example, the <list> element to be referred to among other <list> elements in the shared URI list is identified by the value of “name” attribute or by the name of the <list> element, which is ‘other_friends’. This part that identifies the exact location of the element to be referred is called as reference handle. Therefore, the value of name attribute of XCAP URI in <external> element, which is ‘other_friends’ in this case, becomes the reference handle of <external> element. The same is applied to <resource-list> element of an RLS service document in Table 6.
The <entry-ref> element refers to an <entry> element by specifying the relative XCAP URI of the <entry> element to be referred. The relative XCAP URI is the path that excludes [XCAP Root URL] from the absolute XCAP URI indicating the entire path to the <entry> element. Therefore, the reference by <entry-ref> element can be made only when the [XCAP Root URI] of the referring <entry-ref> element is same as that of the referred <entry> element.
For example, the RLS XDMS 130 storing the rls.xml RLS service document of Table 6 has the same [XCAP Root URL] of ‘http://xcap.example.com/services’ as the shared XDMS 120 which stores the friends.xml shared URI list document of Table 3. Therefore, <entry-ref> element in the rls.xml can refer to <entry> element in the friends.xml. In the example, the <entry-ref> element contains the relative XCAP URI of the referring <entry> element with the URI of ‘sip:brian@example.com’, which is:
resource-lists/users/sip:jay@example.com/friends.xml/~~/resource-lists/list[@name=my_friends]/entry[@uri=“sip:brian@example.com“].
The value of ‘uri’ attribute of the relative XCAP URI in <entry-ref> element, which is ‘sip:brian@example.com’ in the example, becomes the reference handle of <entry-ref> element, because this identifies the exact location of the <entry> element being referred.
As described above, the shared URI list stored in the shared XDMS 120 is utilized for the OMA service in a manner that the shared URI list is referred to through location designation using the <external> element, <resource-list> element, and <entry-ref> element. In this case, the reference handle for location designation is a list name of the referred <list> element in the case of the <external> element and the <resource-list> element, and is a URI of the referred <entry> element in the case of an <entry-ref> element.
While these reference handles of list name and URI value are the key to form the reference relationship between shared URI list and OMA services, it is observed that they are subject to change at the discretion of the user who possesses the shared URI list because the user owning the shared URI list can modify the contents of the corresponding shared URI list through an HTTP PUT based replacement operation whenever desired. However, if the owning user modifies the value of name attribute of the <list> element or that of uri attribute of the <entry> element, all the reference relationship between the shared URI list and other OMA services that have been made regarding the <list> element or <entry> element have to be updated accordingly, as the value of name attribute or uri attribute works as reference handle. Otherwise, the reference relationship between the shared URI list and objects in other OMA services utilizing the shared URI list becomes broken and the objects can no longer utilize the shared URI list.
That is, when values of the “name” attribute and the “uri” attribute, which are reference handles are changed, reference handle values of the <external> element, the <resource-list> element, and the <entry-ref> element respectively corresponding to the shared XDMS 120, the RLS XDMS 130, and the PoC XDMS 140, which are all referring objects, should be updated together to maintain the reference relationship of the shared URI list with the shared XDMS 120, the RLS XDMS 130, and the PoC XDMS 140. Accordingly, modification of reference handle for the referred shared URI list requires separate signaling for update of the referring shared XDMS 120, RLS XDMS 130, and PoC XDMS 140.
FIG. 3 illustrates a signaling for reference update in the shared XDMS, the RLS XDMS, and the PoC XDMS when a reference handle of a shared URI list is changed. The reference update is also performed through the aggregation proxy 110 for the purpose of routing update request to the corresponding XDMS. The user changes the friends.xml document stored in the shared XDMS 120 (301 and 303), changes the friends2.xml document (309 and 311), changes the rls.xml document (317 and 319), and changes the poc_group.xml document (325 and 327). HTTP 200 OK 305, 307, 313, 315, 321, 323, 329, and 331 are response messages. However, since it uses a variable reference handle as described above, the conventional technology has a number of problems.
For example, additional signalings are required to update references of all referring objects in proportion to a utilization degree of referring to the shared URI list in the shared XDMS, which makes an XDMS relationship complex and wastes system resources for additional signaling.
Further, when reference update signaling for referring objects according to a change in the reference handle fails for a certain reason, the referring objects can no longer refer to the shared URI list. This causes an interoperability problem.
Additionally, information about objects referring to the shared URI list needs to be kept in order to suitably update the reference according to change in the shared URI list. As a result, system resources are consumed.